Основная выгод от автоматизации процессов разработки:

— Снижение затрат на разработку

— Уменьшение времени выполнения задач

— Улучшение качества разработки

— Повышение прозрачности и управляемости процесса разработки

— Уменьшение зависимости от сотрудников

К автоматизации процессов разработки относятся:

— Средства автоматизированного планирования и контроля задач

— Статический анализ кода

— Генераторы кода

— Автоматизированное тестирование

— Средства автоматизации деплоя

— Скрипты диагностики

— Скрипты резервного копирования и восстановления резервных копий

— Средства управления инфраструктурой

Для автоматизации процессов разработки применяются инструменты, выбор которых описан выше.

Не рекомендуется автоматизировать процессы, если они еще не эксплуатировались или находятся в состоянии отладки. Это значит, что новый процесс, который еще может измениться, лучше несколько циклов выполнять вручную, пока не зафиксируется его стабильная версия.

Управление продуктом

Жизненный цикл продукта (цели, стратегия, дорожная карта)

Любой продукт — это автоматизация бизнес-процессов. Каждый бизнес-процесс преследуют определенную цель, а их набор в продукте создает определенную ценность для бизнеса. То есть продукт (информационная система) имеет конкретную ценность и целью его (продукта) создания является получение этой ценности.

Жизненные стадии продукта это:

— исследование;

— планирование;

— проектирование;

— изготовление;

— тестирование;

— публикация.

При этом стадии не пересекаются в рамках одной версии продукта:

Продукт может быть:

— Описан

— Спроектирован

— Разработан

— Эксплуатируется

— Архивирован

Стратегия создания продукта может отталкиваться от Гибких границ проекта или от Фиксированных границ проекта. При этом под границами понимаются Стоимость, Требования к продукту, Срок и Качество.

Стратегия развития и дорожная карта должны вести преобразование продукта к определенной цели, которая будет уточняться со временем.

Функциональные характеристики

Проектирование функций (на базе бизнес-процессов)

Функциональные требования к продукту: являются частью описания бизнес-процессов или раскрывают подробности выполнения различных бизнес-процессов. Например, классический интернет-магазин автоматизирует бизнес-процесс коммуникации организации с покупателем, при этом:

— Каталог — выполняет роль справочника по товарам и ценам, некий прайс-лист с картинками. Он трансформировался из бумажного формата в электронный, и хотя способ передачи информации изменился, цель процесса осталась прежней.

— Корзина и оформление покупки — автоматизируют формирование и прием заказа от покупателей. Раньше заказы принимали по телефону или с помощью почтовых отправлений. Карточки заказов шли в бумажных каталогах на последних страницах, чтобы можно было отправить письмом несколько заказов.

— Контакты, О компании… — информирование покупателей об условиях сделки, продавце и т. д.

Процессы могут иметь разные формы при одной и той же цели.

Большая часть бизнес-подразделений недостаточно зрелая для того, чтобы сразу выдавать описанные бизнес-процессы, поддержание которых стоит достаточно дорого для компании.

Продукты могут автоматизировать деятельность клиентов или взаимоотношения с клиентами. При таком раскладе функции продукта проверяются бизнес-гипотезами. Эффективность бизнес-гипотез необходимо подтверждать увеличением вовлеченности, уровнем продаж и др. Другой случай — продукты, которые автоматизируют внутреннюю деятельность предприятий. Они как раз не нуждаются в доказательстве эффективности тех или иных своих функций. Их деятельность уже осуществляется в неавтоматизированном виде, что делает обратную связь от внедрения достаточно быстрой.

Тимлид, как любой другой разработчик, может и должен подсказывать владельцу продукта наиболее оптимальные пути развития. Также в его полномочия входит извлечение данных знаний из всей команды. Это позволит использовать полезные UI элементы и улучшить UX.

Описание функций

В главе «Качество постановки задач» рассматривались различные методы формализации задач. Выбор метода должен быть основан на необходимости более точной (качественной) реализации задач и ориентированы на описание функций продукта.

В некоторых компаниях существуют отдельные аналитики (системные аналитики или бизнес-аналитики), занимающиеся описанием бизнес-процессов или функционала продукта. Бизнес-аналитики фокусируются на проектировании, оптимизации и документировании бизнес-процессов, ролях, должностных инструкциях. Системные аналитики проектируют интерфейсы и их на основании описанных бизнес-процессов. Достаточно часто бизнес-аналитики занимаются системным анализом и наоборот — системные аналитики занимаются бизнес-анализом. Иногда этих специалистов привлекают к оценке бизнес гипотез.

В случае, если в компании нет выделенной роли бизнес-аналитика или системного аналитика, эту функцию может выполнять владелец продукта, тимлид, заказчик и др. Если эту роль выполняете вы сами (тимлид), то вам необходимо придерживаться следующих принципов:

— Постоянно держите в фокусе основную цель продукта и основной бизнес-процесс зарабатывания денег.

— Определите охват продукта и его пользователей.

— Функции продукта должны отвечать потребностям пользователей, а также помогать им более эффективно и качественно выполнять свою роль в бизнес-процессе.

— Проектирование их должно обеспечивать удобство и простоту пользования без чтения документации.

— Система понятно и предсказуемо реагирует на действия пользователей.

— Приятное эстетическое ощущение от интерфейса продукта.

— Обработка ошибок системы, дающая понимание того, что произошло и не требующая от пользователей дополнительных действий.

Нефункциональные характеристики

Архитектура приложений

Тимлид может нести полную ответственность за архитектуру продукта, а может быть подчинен решениям отдельного архитектора. Процесс работы над архитектурой продукта бывает сложным. Он представляет собой совещательный орган, принимающий решения по определенным критериям в необходимых случаях.

Архитектуру информационной системы можно представить в виде слоев:

— Технологический

— Инфраструктура

— Платформа

— Информационный

— Приложение

— Данные

— Бизнес

— Сервисы

— Процессы

— Компетенции

— Ценности

Архитектура — это набор принятых и реализованных решений в отношении элементов (каждого слоя) и их взаимодействия.

Этап первичного проектирования архитектуры часто сопровождается созданием документации — диаграмм и схем. Для этих целей используются UML диаграммы, эта нотация практически не имеет достойной альтернативы на текущий момент.

Проектирование приложения сводится к вопросам:

— Как систематизировать и логически разделить программный код (функциональный, по типу объектов, по слоям объектов, по фичам)

— Уровень отделения логических блоков (монолит, сервисная архитектура)

— Платформа (serverless, на одном сервере, на разных физических серверах, в контейнерах, на виртуальных машинах)

Выбор технологий

Основными критериями при выборе программного языка, фреймворка и инфраструктуры будут:

— Наличие компетенции в технологии

— Способность технологии решить поставленную задачу

— Эффективность решения данной задачи на заданной технологии (стоимость, скорость, расширяемость)

— Доступность компетентных ресурсов в организации в нужный момент времени

Выбор технологий — ответственное решение, которое будет дорого стоить организации. Для того чтобы принять правильное решение, настоятельно рекомендуется проводить встречи и стараться принимать его коллективным путем (это в равной степени относится к архитектуре приложения).

Смена технологий в существующем продукте может быть связана с утратой компетенций или исходного кода. Смена архитектуры более частое явление, так как стоимость этой операции меньше, и она завязана на частых инициирующих событиях (архитектурной ошибке, несоответствии архитектуры текущим потребностям и т. д.).

Архитектурный контроль

Принятые архитектурные решения необходимо реализовать в продукте. Контроль корректности реализации архитектуры продукта — одна из важнейших функций тимлида. Процесс контроля встраивается в процесс ревью